This PR stabilizes all currently stable methods of Ipv4Addr, Ipv6Addr and IpAddr as const.
Tracking issue: #76205

Ipv4Addr (const_ipv4):

• octets
• is_loopback
• is_private
• is_link_local
• is_multicast
• is_broadcast
• is_docmentation
• to_ipv6_compatible
• to_ipv6_mapped

Ipv6Addr (const_ipv6):

• segments
• is_unspecified
• is_loopback
• is_multicast
• to_ipv4

IpAddr (const_ip):

• is_unspecified
• is_loopback
• is_multicast

Motivation

The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized.

There is currently a PR open (#78802) to change the internal representation of IpAddr{4,6} from libc types to a byte array. This does not have any impact on the constness of the methods.

Implementation

Most of the stabilizations are straightforward, with the exception of Ipv6Addr::segments, which uses the unstable feature const_fn_transmute. The code could be rewritten to equivalent stable code, but this leads to worse code generation (#75085).
This is why segments gets marked with #[rustc_allow_const_fn_unstable(const_fn_transmute)], like the already const-stable Ipv6Addr::new, the justification being that a const-stable alternative implementation exists #76206 (comment).

Future posibilities

This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the ip feature (#27709). These methods are already unstable const. There is a PR open (#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on Ipv4Addr::octets and Ipv6Addr::segments (covered by this PR).